|
 |
Chris Huff wrote:
> In article <39228815.F108998C@my-dejanews.com>,
> gre### [at] my-dejanews com wrote:
>
> > 1) int(a)
> > 2) mod(a,b)
>
> The int() and mod() functions are already in POV-Ray, perhaps you mean
> in isosurface functions?
Yep
> > 3) a function that gives the true surface min & max extent of a
> > blob, not its overly spacious bounding box;
>
> The blob object should probably have better bounding_box calculation, no
> need for a new function. In the meantime, you can do this yourself using
> a macro with trace(), there were some posted a while ago.
I wrote my own which calls 2500 trace functions in a grid bounded by min &
max extent. Seems a bit brutish. If mega did this, it would just do the
same thing, you're saying?
> > 4) a function that gives the volume of an isosurface, blob, etc.
>
> Would this really be that useful? I don't know how it would be done...
> I suppose you could approximate this in a macro by using eval_pattern
> with the blob or function pattern, by taking a bunch of samples in a 3D
> grid and discarding ones below the threshold value.
In my world, esoteric math thingies are more fun than photorealism. My
applications may be a bit eclectic and not worth the effort of the whole pov
team's development activity:A) Seeing just how much space is in the
noise3d function. (I'm already working in my head on a way to do this
metallographically).
B) I wanted to make physics-accurate (not merely physically accurate)
motion of a blob character, and I was thinking that knowing its mass
distribution would help.
C) In making advanced flocking algorithms, I was starting to wonder if
it's possible to use the 'mass' of the landscape within a certain radius
that it's about to collide with to guide its direction for graceful, smooth,
near-collisions.
D) If you build it, they will find it useful.
Post a reply to this message
|
|
